Mobility Unified Reporting System Overview

 

This chapter provides an overview of the Mobility Unified Reporting (MUR) application.

This chapter describes the following topics:

•	Introduction

•	MUR Architecture

•	Distributed Architecture of MUR

•	Region-based Reporting

•	Tethering Detection Feature

•	MUR Deployment

•	MUR System Requirements

•

MUR Ports

Introduction

The Cisco Mobility Unified Reporting (MUR) system is a Web-based application providing a unified reporting interface for diverse data from Cisco Systems In-line service and storage applications.

 

The MUR application enables:

•	Generating customized reports and comparison charts.

This release of MUR only supports generating HTML-based historical canned reports displaying data in graphical—graphs/charts—and tabular formats. Reports for ad-hoc periods are not supported. For information on the various reports supported, see the Report Types section.

•	Analyzing the reporting data and enabling the operator to get a full understanding of the performance of the network, enabling operators to optimally configure and plan their network.

•	Supporting distributed installation which allows to view reports from multiple sites.

•	Rich visualization (Graphs/tabular form).

•	Exporting reports in Microsoft Excel, Adobe PDF, and CSV formats.

•	Capacity monitoring and planning of system supporting a suite of products such as PDSN, GGSN, SGSN, and inline service applications like Content Filtering.

The MUR application is available for report generation only when you install the software application on to your local server. For information on the server recommendations, refer to MUR System Requirements section in this guide. For information on how to install the MUR application, refer to Managing MUR Installation chapter in this guide.

The MUR application provides comprehensive and consistent set of statistics and customized reports, report scheduling and distribution from ASR chassis / in-line service product. For example, a subscriber's Quality of Experience, top 10 sites visited, top 10 users, and so on.

The MUR application provides reporting capability for Content Filtering (CF) data, bulk statistics, Key Performance Indicators (KPIs), EDRs data from in-line service and storage applications. The MUR application facilitates and enhances the operators’ ability to simply and easily determine the health and usage of the network.

Important: In RHEL-based deployment of MUR, L-ESS is NOT required as the ASR chassis Enhanced Charging Services (ECS) module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR chassis is the Cisco recommended deployment model. Currently L-ESS is supported only on Solaris platforms. For information on the L-ESS installation instructions, refer to the ESS Installation and Administration Guide. Existing deployments where L-ESS is installed, to pull EDRs from the chassis, may continue with their deployment model in the 12.0 version of MUR Software Release and later.

For information on obtaining and installing the license, see System Administration Guide and Enhanced Charging Services Administration Guide. For information on configuring the ECS module, see Configuring Chassis for Mobility Unified Reporting System chapter in this guide.

MUR receives the following types of EDRs for report processing:

•

CF-EDRs

•

Flow EDRs

•

HTTP EDRs

To reduce disk space and improve performance, MUR limits the bucket distribution for EDR data to ONLY last 2 days in case a EDR is spanning across more than 2 days or so.

For example, if the following EDR is received:

#sn-start-time,sn-end-time,radius-calling-station-id,ip-subscriber-ip-address,sn-subscriber-port,ip-server-ip-address,sn-server-port,sn-app-protocol,p2p-protocol,traffic-type,voip-duration,sn-volume-amt-ip-bytes-uplink,sn-volume-amt-ip-bytes-downlink,sn-volume-amt-ip-pkts-uplink,sn-volume-amt-ip-pkts-downlink,bearer-3gpp rat-type,radius-called-station-id,bearer-3gpp imei,ip-protocol,bearer-3gpp sgsn-address,sn-flow-start-time,sn-flow-end-time 1275330600,1275334200,9689944191,19.19.1.1,35111,1.1.1.1,21,8,,,0,52428800,1048576,100,200,1,apn.org1,35302703-090362-52,6,1.1.1.3,1275330600,1275334200

MUR determines the difference between the starttime and endtime attributes and limits the bucket distribution as shown here.

#starttime,endtime,protocol,rxbytes,txbytes 2011/02/26 10:00:00,2011/02/28 10:00:00,HTTP,100MB,100MB

Important: The bucket distribution calculation will remain intact i.e. the volume will be distributed equally among all the half-hour’s buckets that fall in the starttime and endtime.

Important: The MUR receives the data in terms of EDRs which are generated based on the flow. As the EDRs are flow-based and the bulkstats is a real-time data, the volumes reported in the EDR are different from the volumes reported by bulkstats.

For more information on using the MUR application to generate reports, see the Cisco Mobility Unified Reporting System Online Help documentation.

Report Types

The MUR application supports generation of canned statistical reports that can be used to analyze network performance, and decide the policies for users, and identify the customer trends, network usage patterns, network categorization, etc. The reports can be per gateway, or multiple gateways (region), or for the overall network. The reports can be generated for the usage of different entities such as gateway, content type, etc on an hourly, daily, weekly, or monthly basis.

The typical canned reports that are supported for the MUR application include:

•	Historical summary reports (Daily/Weekly/Monthly)

•	Half-hourly Reports: Usage reporting for the specified time period

•	Daily Reports: Usage reporting for the past 24-hour period (midnight through midnight)

•	Weekly Reports: Usage reporting for the past seven day period (Monday through Sunday)

•	Monthly Reports: Usage reporting for the past 30-day period (1 day of the month through the last day of the month)

•	Top “N” Reports

•	Statistical and analytical reports

•	Bulkstats and KPI reports

The static report layout comprises the following sections:

•	The report name

•	The report ownership: the user account that requested the report

•	The date and time of generation

•	The list of report parameters

•	The chart legend (displayed under the chart)

On the interactive layout the user can set a series of preferences in a specific manner. The user has the flexibility to change the type of chart from Bar to Pie (supported output types depend on the selected report). Changing the preferences like the chart type or report parameters will cause the report to refresh in the same window.

The interactive chart layout provides the following list of features:

•	Tool tip: When the mouse pointer stops over a chart series, after a short time a tool tip is displayed showing the information of the targeted sample.

•

Dynamic legend: The legend is located beneath the chart and is used to recognize the series plotted on the screen. In case of series representing either network services or subscriber packages, the colors are bound to the service/package names. This means that, for example, the HTTP Service will be rendered with a specific color for the reports. The legend is usually displayed with check-boxes associated to each color.

The MUR application provides the following reports:

•	Traffic Analysis Report: The Traffic Analysis report provides the total usage traffic (including uplink and downlink traffic) details for the following application categories:

•

Video

•	Filesharing

•

Web

•

IM

•

VOIP

•

Standard

•

Streaming

•

Tunnel

•

Gaming

•	Unclassified

MUR supports traffic type detection for P2P protocols such as Skype, Gtalk, MSN, Yahoo, and Oscar with the use of “traffic-type” attribute present in the EDR fields. Based on the value of this EDR attribute, the data will be classified to respective protocols.

The usage traffic is expressed in terms of megabytes (MB) or Megabits per second (Mbps) and percentage (%). The traffic can also be in gigabytes (GB) / kilobytes (KB) / bytes depending on the magnitude.

•	Traffic Distribution Report: The Traffic Distribution report provides the summary of total traffic distribution for all the protocols application categories over a specified time period. The usage traffic is represented in GB/MB/KB/Bytes and percentage.

•	Active Flow Count Report: The Active Flow Count report provides the details of traffic distribution flow count against the different application categories. This report also provides the summary of maximum number of flows in the EDR records.

Important: Active Flow Count report for current date will not be available because daily tables used to fetch this report are generated only at the end of the day. Also when the user selects a date range, for example, 10/1/2011 to 10/5/2011 where 10/5/2011 is the current date, then the report will be shown for the period 10/1/2011 to 10/4/2011 i.e. up till 10/4/2011.

Release 12.2 onwards, the Active Flow Count report will show flow counts for a sample/bucket (as per the configured granularity) that has maximum number of flows for selected filters in flow count summary. This new behavior is applicable to data ONLY after upgrading MUR to 12.2 version. Previous data will be shown as per the old reporting behavior.

•	Unique Subscriber Hits Report: The Unique Subscriber Hits report provides an overview of the usage patterns of the entire subscriber population per protocol, for example, how many people are actually using VoIP.

Important: Unique Subscriber Hits report can be generated ONLY for a single date/week/month and not for any date-range. Also, note that the time selection is also disabled for this report.

Typically, this report provides the total number of times a subscriber is using a specific protocol. These reports are displayed for all configured gateways.

Important: Unique Subscriber Hits report for current date will always be available on the subsequent date because unique subscribers hits calculation will be performed at the end of the day.

•	TopN versus Total Traffic Report: This report provides the summary of total usage traffic and Top N subscriber traffic for all the protocols over a specified time period. The usage traffic is represented in GB/MB/KB/Bytes and packets.

•	Session Duration Report: A session is defined as the combination of GGSN address and charging identifier. Two GGSNs can have the same charging ID. Charging identifier is used together with GGSN address to identify all records produced in SGSN(s) and GGSN involved in a single PDP context.

Session duration is the time difference between start time and end time for that session. This reports the statistical analysis of user sessions over the session duration.

•	TopN Subscribers Report: The TopN Subscribers report simply counts the number of bytes per subscriber for different time intervals. It displays the top 10/100/1000 subscribers for each day/week/month. This report is displayed across all configured gateways, per region or per NOC.

Important: This report is not available for a multiple date range selection.

After identifying the total amount of transferred data per subscriber, and identifying the top users, to understand the protocol and services breakdown for each subscriber, this report allows listing the different applications used by the top 10/100/1000 subscribers based on the selection of top subscriber per day/week/month.

•	TopN VCD Subscribers Report: The TopN Voice Call Duration (VCD) Subscribers report displays the top N subscribers based on their voice usage (voice duration) for Yahoo, MSN and Skype voice protocols. The summary report displays the voice summary (voice duration) for VoIP category.

Important: This report is also available per week or month.

•	Weekly Report: The weekly report provides details of the following:

•	Total traffic

•	Total traffic by category

•	VOIP Call Duration

•	Total unclassified traffic (TCP and UDP)

•	Top N subscribers

•	Monthly Report: The monthly report provides the details of total traffic across the top N protocols / application categories in a month.

•	Custom Reporting: MUR supports on-demand offline reporting of subscriber specific information to operators. This ad-hoc request could be a subscriber search request or top N search request.

Offline Subscriber Report: The MUR aids in searching individual subscribers’ data based on certain parameters like IMSI, MSISDN, NAI, IMEI and Public and Private (NAT) subscriber IP address with ports, individually or in combination, and generates a subscriber-specific report showing the list of URLs visited by the subscriber, and other details like QoS, usage traffic, aggregate application/protocol breakdown, etc for the specified time period. MUR mainly supports this search functionality to track a subscriber or a set of subscribers for lawful intercept.

To use this Offline Reporting feature seamlessly, you must configure the EDR Filename Format appropriately through the Gateway configuration from ADMIN tab, and organize the archive directory date-wise. For information on how to manage the archive directory, see the Managing Archive Directory section in the MUR Administration and Management chapter of this guide.

Offline Top N Subscribers Report: MUR also facilitates to generate an offline report that covers the % of volume/duration used by top n% subscribers. This report provides information on the absolute number of subscribers and the list of MSISDNs to facilitate correlation with the provisioning data. In this release, this ad-hoc report is available per APN group, Device Group, Location Group, and Service Profile.

Through this custom TopN reporting feature, it is possible to monitor and report the video traffic usage as and when needed. This report is mainly required to identify TopN hosts for video traffic and also to determine the biggest sources of video traffic, which drives the network load at a greater extent.

HTTP content type will be used to identify the video traffic. Ideally video traffic should be derived from flow-EDRs. Since the video usage monitoring report is generated based on HTTP content type, only HTTP traffic will be counted.

For more information on these features, see the Cisco Mobility Unified Reporting System Online Help documentation.

Reports based on Tethering Configuration: Tethering refers to the use of a mobile smartphone as a USB dongle/modem to provide Internet connectivity to PC devices (laptops, PDAs, tablets, and so on) running on the smartphone's data plan. Typically, for smartphone users, most operators have in place an unlimited data plan, the usage of which is intended to be from the smartphone as a mobile device. However, some subscribers use the low cost / unlimited usage data plan to provide Internet connectivity to their laptops in places where normal Internet connection via broadband/WiFi may be costly, unavailable, or insecure.

The ASR chassis works in conjunction with the MUR application to facilitate tethering detection on the chassis. The EDRs generated by the chassis will be enhanced to include OS signatures.

MUR processes flow-EDR files containing OS signature and IMEI field, HTTP files containing User Agent and IMEI field, and populates the tethering data in database files.

For more information on this feature, see the Cisco Mobility Unified Reporting System Online Help documentation and 12.2 Enhanced Charging Services Administration Guide Addendum.

•	DPI Report: The Deep Packet Inspection (DPI) reports are the canned statistical reports at the gateway level and region level. You can configure the MUR application to generate the reports for any of the available gateways.

In this release, MUR supports generating daily, weekly and monthly summary details and busy hour traffic usage details for the following report categories:

•	Traffic Analysis Report

•	Traffic Distribution Report

•	Active Flow Count Report

•	Unique Subscribers Hits Report

•	TopN Reports — Report on Top N vs Total Traffic, TopN subscribers, TopN VCD subscribers

•	Session Duration Report

Important: Release 12.2 onwards, users with only administrative privileges can decrypt the subscriber’s MSISDN to make it appear in the clear text format in the weekly reports.

MUR has the capability to report the following details per protocol:

•	Total volume for the day/week/month

•	Volume distribution in the busy hour

•	Peak performance for the day/week/month

•	Maximum number of unique subscribers

•	Number of sessions hosted by GGSN service and the corresponding duration

MUR supports additional information breakdown by network characteristics. These include Application Category, Protocol Groups, IP Protocol, Device Group, RAT (Radio Access Type i.e 2G vs 3G), APN (Access Point Name), SGSN group, Service Profile, Roaming Partner, and Location Group. During its development, a device may have several TAC codes and there may be a need to report devices by broader device type such as "Blackberry" or "Smartphone". Device groups allow the operator to combine a range of TACs into a single named group for reporting purposes.

Busy Hour Reporting: Busy Hour (BH) reporting is mainly useful for the users to monitor different traffic flows in their network during the busy hour. BH indicates the sliding 60-minute period during which occurs the maximum total traffic load in a given 24-hour period.

Please note the following key points:

•	BH reporting is available ONLY on the GUI and not in xls format.

•	BH reporting is available only under the DPI tab.

•	BH radio button is available on the date panel.

•	BH reporting is available for a date, date range, week and month.

•	Busy hour reports are currently available ONLY at the NOC level.

DSL Reports: The current release of MUR provides the following details for Digital Subscriber Line (DSL) traffic reports:

•	Traffic analysis — uplink DSL, downlink DSL and total DSL traffic including daily weekly, and monthly aggregation/distribution.

•	DSL traffic categorization — total P2P traffic over DSL, IP traffic, web traffic, etc.

•	Top N% DSL subscribers

•	Comparison of total DSL traffic versus total UMTS traffic

For information on additional reports supported through DPI, see the Cisco Mobility Unified Reporting System Online Help documentation.

•

CF-RE Report: Content Filtering (CF) solution enables operators to filter HTTP and WAP requests from mobile subscribers based on the URLs in the requests, so that subscribers are inadvertently not exposed to universally unacceptable content and/or content inappropriate as per the subscribers’ preferences.

The CF-RE report provides the summary of traffic over CF categories, CF actions, and CF ratings. The CF actions that can be taken on the URL are as follows:

•

allow

•

discard

•	redirect-url

•	content-insert

•	terminate-flow

•	reply-code-terminate-flow

The CF ratings can be one of the following:

•

dynamic

•

static

•	blacklisted

The CF-RE report also provides the list of top N subscribers and URLs based on their unique subscriber’s hit count and total usage.

•	HTTP Reports: The MUR application parses HTTP EDRs and then provides the following details for any specific day, week, month and date range:

•	Total traffic per HTTP group / host name and HTTP content type

•	URL hits per HTTP group / host name and HTTP content type

•	Unique subscriber count per HTTP group / host name

Typically, MUR supports the following categories of HTTP reports:

•	Summary reports — Content type/subtype volume report available for daily, weekly, monthly, and date range

•	Top N reports (Daily/Weekly/Monthly)

•	HTTP Group Aggregation — TopN HTTP group by Volume; TopN HTTP group by Hit count; TopN HTTP group by Unique subscriber hits

•	Top N Referrer Group Aggregation by Hit count

•	TopN User Agent (UA) reports available for APN-TAC combination in addition to individual per APN, per TAC reports.

•	HTTP Services Aggregation — TopN HTTP Services by Volume; TopN HTTP Services by Hit count

The top N referrers’ report provides details of the total hit count for top N referrers and their sub-domain wise traffic distribution.

Important: In the distributed model of MUR, the data received from RDP is populated and TopN referrer report is available only at NOC level.

Important: It is mandatory to configure http-url and http-referer fields in the EDR records for top N HTTP referrers report generation.

•	Top N Unknown Ports: This report highlights the top N ports for which traffic is classified as either unidentified or unknown. This report also lists the underlying IP protocol, downlink volume (in Megabytes), uplink volume (in Megabytes) and total volume (in Megabytes).

The report on top N unknown ports can be viewed through the link Edr unknown port infos under the System menu.

•	Bulkstat Report: The Bulkstat report provides details of the processed bulk statistics from any application (PDSN, GGSN, SGSN, and so only) on the managed nodes in a timely manner.

Important: Make sure that you configure the bulkstats schemas through the GUI to generate bulkstats reports for any of the available gateways. For more information on schema configuration, refer to the Configuring Bulkstats Schemas Using GUI section in this guide and also Cisco Mobility Unified Reporting System Online Help documentation.

The bulkstat data is sent from the gateway to the MUR server with GMT (UTC Time stamps). The bulkstat file processing is triggered by the MUR scheduler engine. The scheduler processes the bulkstat files line by line for each gateway, and gets the schema, timestamp, and key index. If the index does not exist, the parser creates index and inserts data into bulkstats data table. Once the processing is complete, this data file is moved to the archive directory. Summarization must happen as the user moves from gateway to higher levels.

Important: For Bulkstat, there is no support for distributed model and all the bulkstat input files will be parsed by master MUR system only.

MUR supports generation of busy hour reports, top N Min/Max reports, performance aggregation reports i.e. daily, weekly and monthly summary reports.

Please keep the following key points in mind for bulkstats reporting:

•	The gateway(s) and MUR server need to be NTP synced for accurate BS aggregation reports.

•	Hourly aggregation reports are triggered at 50th minute of every hour.

•	Daily reports are scheduled at 3:45 PM the next day.

•	Weekly reports are scheduled at 5:00 PM every Monday.

•	Monthly reports are scheduled at 06:15 PM on 1st of every month.

•

KPI Report: The KPI report provides details of the KPIs for each selected schema. KPIs are the formula-based calculations of selected bulk statistics counters. You can configure the MUR application to generate the reports for any of the available gateways. For a complete listing of supported KPIs and its associated formulas/descriptions, see the Cisco Mobility Unified Reporting System Online Help documentation.

Important: Please note that the Bulkstats and KPI reports are displayed based on the gateway’s time zone.

Important: Please note that the subscriber’s private data like Mobile Station Integrated Services Digital Network (MSISDN) will appear encrypted in all the subscribers reporting. Users with administrative privilege can only decrypt the MSISDNs using a shell script utility. For information on how to use this script, refer to the MUR Administration and Management chapter in this guide. The MSISDN decryption can also be accomplished through Admin > Users menu in the GUI. For decryption through the GUI, see the Cisco Mobility Unified Reporting System Online Help documentation.

Important: Please note that the availability of any report is typically based on the date/date range configurations and purging interval. If you are trying to view a report beyond the configured purging interval, MUR system will display an error message indicating that the report is unavailable.

For more information on each of these reports, see the Cisco Mobility Unified Reporting System Online Help documentation.

Exporting Reports to Other File Formats

The MUR application supports exporting reports to the following file formats:

•	Microsoft Excel format: To export a report to Microsoft Excel format, use the get_excel_report script in the CLI. For more information about this script, refer to the Generating Reports in Excel Format section in the MUR Administration and Management chapter of this guide.

Exporting of reports to Excel format is also possible through the GUI by clicking the excel icon present in the tabular view of each of the reports under HOME and DPI tabs.

•	Comma Separated Value (CSV) file format: To view reports in CSV format, in the HOME and DPI tabs, click the csv icon present in the tabular view of each of the reports.

•	PDF format: To export a report to PDF format, in the HOME and DPI tabs of the MUR GUI, click the PDF button. The PDF file is displayed in a new window and can be saved for future reference.

If there is no data available for a report, the PDF button is disabled.

•	Text File format: This format is applicable only to HTTP User Agent (UA) reports. To export this report in a text file, click Export to Text button available in the HTTP UA reporting page.

For more information, see the Cisco Mobility Unified Reporting System Online Help documentation.

License Requirements

The MUR system is a licensed Cisco product. Contact your Cisco account representative for detailed information on specific licensing requirements.

MUR Architecture

The MUR solution consists of two components — a server and a GUI client. The following figure shows a typical organization of the MUR solution.

Internal Architecture of MUR

The server components include:

•	DB Server: This is the standard PostGreSQL 8.3 database server. This is started at the time of application startup.

MUR uses pgbouncer utility for postgres connection pooling. This utility gets started/stopped with Postgres Server.

•	Quartz Scheduling Engine: This is the core of the MUR reporting solution. It is used to schedule different tasks such as parsing of incoming data files (bulkstat, EDR, etc.), trigger various canned reports on a periodic basis, cleaning up of stored outdated data and files, and so on.

•	Generators: These are python based scripts that are used for parsing various CSV files. The files are parsed to an extent where generated files (or data in database) themselves represent meaningful data. This is a very powerful concept introduced for faster processing of information.

The generators archive the files once they are parsed. In archival, the files are zipped and placed in the configured location.

•	KPI Parser: The KPI Alarm Generator uses the information stored by bulkstat parser in the database for KPI calculations and then, based on the calculations, generates the alarms that are subsequently sent to Network Node Manager (NNM).

•	Notif Server: This stands as a separate entity that collects information from the MUR system and generates alarms which are then sent to the NNM for further analysis.

•	Loggers: The MUR application uses various loggers so that application logs with various severities are made available for debugging purpose.

•	MUR Parser Server: This will be running as daemons, and it will be spawned at the time of serv start command. Parser server will keep running in background and will perform the parsing activity for all gateways.

The following is a sample output of the serv status command:

---------------------------------------------------

--------------- MUR Process Status ------------

 PID            Process                  Status

---------------------------------------------------

4245          Process Monitor           Running

4256          Scheduling server        Running

4267          Postgres Server         Running

4289          Apache Server           Running

3249          Notif Server           Running

3243          Parser Server           Running

2430          Cache Server           Running

---------------------------------------------------

The following describes the sequential steps associated with the functioning of RPC parser daemons.

1.	For each configured gateway, RPC Parser daemon will check if the appropriate reporting (Flow/HTTP/CF) is enabled or not.

If say, Flow-EDR reporting is enabled for GW1, RPC Parser daemon will check the Process Count configured for Flow-EDR under System menu.

2.	Depending on the number of processes configured, RPC Parser daemon will spawn those many RPC server instances for GW1. Also, it will update each RPC server URL in DB as shown below:

ID	Gateway ID	Reporting Type	RPC Server URL	Process ID
1	1	Flow-EDR	http://localhost:8000	7643
2	1	Flow-EDR	http://localhost:8001	8756
3	1	Flow-EDR	http://localhost:8002	9054
4	1	Http-EDR	http://localhost:8003	5645
5	1	Http-EDR	http://localhost:8004	6576
6	1	Http-EDR	http://localhost:8005	8678

‌

3.	Steps 1 through 3 are repeated for each configured gateway and reporting type.

4.	Normalization daemon will pick up the set of files to be parsed. Depending on the number of files to be parsed, it will get the corresponding RPC server information from DB from the above table.

5.	Depending on the number of files to be parsed, normalization daemon will spawn those many threads. Each thread will allocate its bunch of files to corresponding RPC server instance. The RPC server instance will parse and store the normalized data in DB and the corresponding thread will exit.

6.	If the Process count is increased/reduced, additional RPC server instances will be fired/closed as and when required.

7.	Both the normalization daemon and RPC Parser daemon will be continuously running in background.

8.	Normalization daemon will be spawned by the scheduler initially. RPC Parser daemon will be spawned through serv start command.

Some of the components at the client side include Django and Mod_python.

Distributed Architecture of MUR

MUR supports the distributed model to allow the deployment which enables network wide view or work load balancing. Newly introduced component, Remote Data Processor (RDP), plays the role of pre-processing the input files from gateways. One or more RDPs, installed separately on remote machines can be registered to a master MUR and one RDP can process files from one or more gateways.

RDP periodically sends the intermediate data to registered master MUR. The role of MUR in such deployments is mostly for report generation, report viewing, RDP management and optionally data processing.

Important: RDP installation and registration is required only for network wide deployments. For standalone installation no RDP is required. For information on how to install the RDP, refer to the Managing MUR Installation chapter of this guide.

Important: Make sure that you first install the master MUR system and then proceed with the RDP installation. Also, note that the RDP and MUR must be installed, upgraded, and uninstalled separately.

Important: Before registering RDP with the master MUR, ensure that the RDP is installed and running.

Important: The RDP management like configuration and removal is possible from MUR GUI only. For information on managing the RDPs, refer to the Cisco Mobility Unified Reporting System Online Help documentation.

Important: For Bulkstat, there is no support for distributed model and all the bulkstat input files will be parsed by master MUR only.

The following figure illustrates the distributed architecture of MUR.

Distributed Architecture of MUR

How RDP works with MUR

This section describes how the RDP works with the MUR application.

The RDP parses the raw data or EDR files from one or more GGSNs and populates the database for required reports. The RDP pre-processes the data and then periodically forwards them to the master MUR through SFTP for report generation.

Important: If the distributed model of MUR is used, then the SFTP user name and password should be the same as the MUR Administrator user’s login name and password provided during installation. For information on configuring SFTP details, see the Cisco Mobility Unified Reporting System Online Help documentation.

Each of the RDP and MUR will be assigned a unique ID during installation and will be used for identification of each RDP along with its gateway and data.

MUR with RDPs in Distributed Model

In 12.0 and earlier releases, each of the registered RDPs will form a new region. RDP region can be a child of the root of the MUR (NOC) or can be the child of another region. The gateways associated with a RDP will always be the children of RDP region.

Release 12.2 onwards, users can create individual regions and add RDPs to the regions. All the gateways must be associated with RDP(s) or NOC and not to a region directly.

Important: Only single MUR can communicate with an RDP simultaneously.

Region-based Reporting

In 12.0 and earlier releases, RDP was considered as a region. So, all reports were based on RDP. Whenever an RDP is configured, internally MUR used to create corresponding region for the same. However, with the introduction and need of scalable MUR, one gateway's files will be processed by two or multiple RDPs. In that case, RDP does not stand as a region. So, reports will be required across all the RDPs under one specific region. Particularly, when there are multiple such regions where each region has more than one RDPs, this feature becomes more important. A different case for the requirement of this feature is a region where there are multiple gateways and they are processed by different RDPs. In that case, per RDP based reports will not make sense, rather, region based reports will be required.

Important: In the gateway tree in DPI, HTTP, CF and Bulkstats tab, the pseudo gateway is NOT shown. This is because, there are no specific reports to the gateway, it is just a pseudo to original gateway and all the data is coming from the original gateway only.

Tethering Detection Feature

Important: In the current 12.2 release, the Tethering Detection feature is supported only on the GGSN.

Tethering refers to the use of a mobile smartphone as a USB dongle/modem to provide Internet connectivity to PC devices (laptops, PDAs, tablets, and so on) running on the smaprtphone's data plan. Typically, for smartphone users, most operators have in place an unlimited data plan, the usage of which is intended to be from the smartphone as a mobile device. However, some subscribers use the low cost / unlimited usage data plan to provide Internet connectivity to their laptops in places where normal Internet connection via broadband/WiFi may be costly, unavailable, or insecure.

The Tethering Detection feature enables detection of subscriber data traffic originating from PC devices tethered to mobile smartphones, and also provides effective reporting to enable service providers take business decisions on how to manage such usage and to bill subscribers accordingly.

Important: Use of Smartphone tethering detection feature requires that a valid license key be installed. Contact your local Sales or Support representative for information on how to obtain a license.

For detailed information on this feature, refer to 12.2 Enhanced Charging Services Administration Guide Addendum.

MUR Support for Tethering Detection

The ASR chassis works in conjunction with the MUR application to facilitate tethering detection on the chassis.

MUR is used to collect samples of HTTP and TCP signatures from live traffic to create a database of OS and UA signatures for assorted devices accessing the network through the gateways. For this, offline TAC-device mappings are fed to MUR, and MUR generates the signature databases based on EDRs generated by the chassis for various TAC groups.

Upon enabling tethering detection feature through the GUI, MUR collects samples of HTTP and TCP signatures from live traffic and creates a database of OS and UA signatures for assorted devices accessing the network through the gateways. For this, offline TAC-device mappings are fed to MUR, and MUR generates the signature databases based on EDRs generated by the chassis for various TAC groups.

MUR processes flow-EDR files containing OS signature and IMEI field, HTTP files containing User Agent and IMEI field, and populates the following set of data in the respective database files.

•	Laptop (USB Dongles device group) - User Agent data

•	Laptop (USB Dongles device group) - OS Signature data

•	Smartphone - TAC data

MUR is configured in such a way that the database files are pushed to the ASR chassis under the /mnt/hd-raid/data/databases/ directory.

For information on how to confiugre tethering detection feature, refer to Configuring Chassis for Mobility Unified Reporting System chapter in this guide.

Tethering Detection Databases

The Tethering Detection feature uses the OS signature, UA signature, and TAC databases.

These database files must be populated and loaded on to the chassis by the administrator. The procedure to load the databases is the same for all the three types of databases.

Before the database(s) can be loaded for the first time, tethering detection must be enabled using the tethering-database CLI command in the Active Charging Service Configuration Mode.

For all three databases, only a full upgrade of a database file is supported. Incremental upgrade is not supported. If, for any particular database, the upgrade procedure fails, the system will revert back to the previous working version of that database.

OS Signature Database

The OS signature database file is named “os-db”. The file contains OS fingerprint signatures that have been identified as non-smartphone signatures.

The OS fingerprint signature string is a null-terminated ASCII string of maximum 32 bytes in the following format:

<tlen>|<ttl>|<d>|<wlen>|<mss>|<wss>|STEN

Where:

•	tlen: Total IP Packet Length

•	ttl: Initial TTL

•	d: IP DF bit

•	wlen: TCP Window Length

•	mss: TCP Maximum Segment Size

•	wss: TCP option Window Size Scale

•	S: TCP option Selective ACK OK

•	T: TCP option Timestamp

•	E: TCP option EOL

•	N: TCP option NOP (count)

The maximum number of entries permitted in the os-db file is 16384.

The maximum size of the os-db file can be 524KB + 50 bytes for header and trailer.

In the 12.2 release, the file is in plain text format and contains one TCP signature in ASCII format, one entry per line.

The following is the content of a sample os-db file:

VERSION 1.1

BEGIN OS-DB

48|128|1|5840|1460|1|1112

44|128|0|5840|1460|1|1011

END OS-DB

UA Signature Database

The UA signature database file is named “ua-db”. The file contains UA signatures that have been identified as non-smartphone signatures.

The UA signatures are stored in plain text format in the database file so that manual modification of the database is possible.

The maximum number of entries permitted in the ua-db file is 16384.

The maximum size of the ua-db file can be 67MB + 50 bytes for header and trailer.

The following is the content of a sample ua-db file:

VERSION 1.1

BEGIN UA-DB

Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.1; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; InfoPath.2)

END UA-DB

TAC Database

The TAC database file is named “tac-db”. The file contains smartphone TACs that are uploaded in MUR by the operator.

The maximum number of entries permitted in the tac-db file is 16384.

The maximum size of the tac-db file can be 147KB + 50 bytes for header and trailer.

The following is the content of a sample tac-db file:

VERSION 1.1

BEGIN TAC-DB

01194800

01194801

END TAC-DB

Loading and Upgrading Tethering Detection Databases

This section provides an overview of loading and upgrading the OS, UA, and TAC databases used in tethering detection.

The database files from MUR must be copied onto the chassis to the following directory path designated for storing the database files:

/mnt/hd-raid/data/databases/

Any further upgrades to the database files can be done by placing the file named new-filename in the designated directory path. ACS auto-detects the presence of files available for upgrade daily. When a new version of a file is found, the upgrade process is triggered. The upgrade can also be forced by running the upgrade command in the CLI. On a successful upgrade this file is renamed to filename.

MUR Deployment

The following figure illustrates how the MUR reporting server interacts with the gateways and generates the reports.

End-to-end Component Mapping

The chassis / gateway supports on board Hard Disk Drive (HDD) for extended storage of the xDR files such as EDR, UDR, CDR, and NBR. If the HDD is configured, then the gateway pushes the files to an external entity like External Storage Server (ESS) for short-term storage. In case of no HDD support on the gateway, the Local, short-term External Storage Server (L-ESS) has the capability of pulling the files from gateways via SFTP, and send it for report processing. For more information on L-ESS, refer to the ESS Installation and Administration Guide.

The MUR server collects the EDRs, and bulkstats from gateways or L-ESS server, and processes the incoming data files and presents reports on Web-based GUI. The MUR application can generate reports in Excel, CSV, and PDF formats, and present them to users on a request basis.

Important: L-ESS is NOT required as the ASR5K EDR module can be configured to push the xDRs directly to the MUR reporting server. Push from ASR chassis is the Cisco recommended deployment model. Currently, L-ESS is supported only on Solaris platforms. For information on the L-ESS installation instructions, refer to the ESS Installation and Administration Guide. Existing deployments where L-ESS is installed, to pull EDRs from chassis, may continue with their deployment model in the 12.0 version of MUR Software Release and later.

For information on how to configure the chassis to push the xDRs, refer to the Configuring Chassis for Mobility Unified Reporting System chapter in this guide.

MUR System Requirements

This section identifies the minimum system requirements that are required for the deployment of MUR at the operator’s premises.

Important: The hardware required for MUR may vary depending on incoming EDR generation, subscriber count, and number of gateways.

Server Recommendations for Use in Solaris Environment

This section identifies the minimum system requirements recommended when installing the MUR application in Solaris environment.

NEBS Requirements:

The following are the server specifications for MUR when an additional external storage is required:

•	Sun Microsystems Netra™ X4270 server

•	Quad-Core two socket Intel Xeon L5518 processor

•

32GB RAM

•	2 * 300GB 10K RPM SAS disks

•	SATA DVD drive

•	8 internal port SAS HBA

•	Choice of AC or DC power supplies

•	Sun StorageTek 2540 SAS Array, Rack-Ready Controller Tray

•	12 * 300GB 15K RPM SAS drives

•	Two redundant AC power supplies

•	Operating system:

•	Sun Solaris 10 with latest patches installed

Non-NEBS Requirements:

The following are the server specifications with only the internal storage used:

•	Sun Fire X4270 server

•	Intel Xeon processor 5500 series

•

32GB RAM

•	16 * 300GB 10K RPM SAS disks

•	SATA DVD drive

•	Operating system:

•	Sun Solaris 10 with latest patches installed

Important: It is strongly recommended to update the Operating System with the latest security patches.

Important: The number of disks recommended is purely based on the throughput of the network and data retention configuration. Please contact Cisco Advanced Service Team for data sizing.

ZFS Pooling Recommendations:

This section provides information on the recommendations for ZFS pooling.

•	OS pool: This mirrored ZFS pool shall be created for Solaris OS installation.

•	MUR pool: This standard ZFS pool shall be created for MUR i.e. MUR installation, incoming data files.

•	Postgres pool: This standard ZFS pool shall be created for MUR postgres database.

•	Archive pool: This standard ZFS pool shall be created for retaining archived and data backed up files.

Important: ZFS pool shall NOT be created with RAID-Z since ZFS does not allow attaching an additional disk to an existing RAID-Z pool. Hence, this freezes the chances of data scaling.

Server Recommendations for Use in RHEL Environment

This section identifies the requirements of server recommended when installing the MUR application in RHEL environment.

•	UCS C460 M2 server

•	4 x Intel® Xeon® E7-4860 @ 2.26 GHz, 130W 10 Core CPU / 24 MB Cache

•

128GB RAM

•	12 * 600 GB SAS 6G, 10K RPM

•	RAID Controller

•	4Gb Dual port FC Host Bus Adapter

Important: The number of disks recommended is purely based on the throughput of the network and data retention configuration. Please contact Cisco Advanced Service Team for data sizing.

•	Operating System

•	Cisco UCS running OS version ‘Cisco MITG RHEL 5.5’

For information related to OS installation, refer to the Cisco MITG RHEL OS v5.5 Application Note.

Important: The Cisco MITG RHEL v5.5 OS is a custom image that contains only those software packages required to support compatible Cisco MITG external software applications. Users must not install any other applications on servers running the Cisco MITG v5.5 OS. For detailed software compatibility information, refer to the Cisco MITG RHEL v5.5 OS Application Note.

Important: ZFS Pooling recommendations are applicable ONLY for Solaris hardware.

•	XFS/EXT-3 File System Volumes & RAID Recommendations

Storage RAID recommendation for MUR Application

CISCO UCS machine supports MegaRAID controller. This allows configuring the UCS hard disks into hardware RAID arrays (disk groups). The MegaRAID controller provides the BIOS utility for configuring the RAID.

The RAID recommendations for MUR are as follows:

•	Separate disk arrays for OS, MUR and postgres (data directory).

•	RAID Level - Combination of 5 and 0 depending upon the fault tolerance.

•	Stripe size should be 256KB

•	RAID Controller parameters —

•	Read Policy - Select Adaptive read ahead

•	Write Policy - Select Write Back

•	I/O Policy - Select Direct I/O

For information on configuring the RAID arrays using MegaRAID BIOS, refer to the Configuring Cisco UCS Servers for MUR System Application Note.

Storage Recommendation for MUR Application

This section provides the storage recommendations needed for the MUR application.

•	Separate storage (single disk or RAID array) for OS. (root and swap space partitions)

•	Two RAID arrays: RAID-0 for MUR application and RAID-5 for database (Postgres data directory).

•	LVM: Separate physical volume and volume groups for the three RAID array disk groups.

•	XFS file-system: block size 4KB, s-unit in terms of RAID stripe size (256KB) and s-width in terms of span of disks in the RAID array.

For information on how to partition storage disk and configure XFS file system, refer to the Configuring Cisco UCS Servers for MUR System Application Note.

MUR Ports

This section provides information on various ports and their corresponding port numbers used by the MUR application.

Various ports are used by the MUR for both client-server communication and communication with ASR chassis. If firewalls are used on these interfaces, these ports need to be opened.

The following table lists the ports that are used by MUR.

Default Port Utilization

Port Name	Port Number	Usage
TCP Port	22	This port is used by MUR administrator to connect via SSH to UNIX command line on MUR servers for system administration. This port is also used by gateway to upload files via SFTP to MUR servers (stand-alone master and RDPs), and also by RDPs to upload files to the master. In the case of pull model, the L-ESS process on the RDPs or stand-alone master will use SFTP to connect to this port on the gateway. This port is also used between master MUR server and gateway to configure and upload bulkstat files.
TCP Port	25	This port is used to send e-mails to a mail server in case these are configured to deliver reports and alarms.
UDP Port	162	This port is used to send traps to the northbound network management system.
Postgres Port	5432	This port is used by the local processes to access the PostgreSQL server and can be restricted to prevent external access.
Apache Port	8080	For a standalone model: This port is used for communication between client workstation and Apache Webserver on MUR via HTTP. For distributed model: This port is used for both Master to RDP and RDP to Master RPC communication. Important: When firewall is used, Apache is the only port that should be kept opened.

‌

Typically, MUR starts all its related services with non-root (i.e. muradmin) privileges.

Firewall Settings

When MUR is running on RHEL platform, Firewall is ON by default. In that case, user will NOT be able to get access to MUR GUI. The Firewall MUST be disabled with the following commands:

service iptables save

service iptables stop

chkconfig iptables off

Using Apache Port

This section provides information on how to configure the Apache port to use in conjunction with the MUR reporting server.

Using Apache in Solaris

In case the user wants to configure Apache port as 80 (i.e. < 1024), it is necessary to run the following command as root user so that muradmin can start the services on ports < 1024.

usermod -K defaultpriv=basic,net_privaddr <mur admin user>

Using Apache in RHEL

Important: Make sure that you disable Firewall before using the Apache port in the RHEL environment.

RHEL does not allow port 80 to be used by non-root users. However, Apache Web server requests made on port 80 can be redirected to a port >1024 defined by the operator, with the following two commands:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j REDIRECT --to-port <user defined port> 1024>

iptables -t nat -AOUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-port <user defined port> 1024>

For example, to redirect requests made on port 80 to port 8080:

iptables -t nat -A PREROUTING -p tcp --dport 80 -i eth0 -j REDIRECT --to-port 8080

iptables -t nat -AOUTPUT -p tcp -d 127.0.0.1 --dport 80 -j REDIRECT --to-port 8080

Once this is done, user will be able to access the MUR GUI directly, without specifying the port in the Web browser URL http://<serveripaddress>.

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883